Towards an OWL-formalization of the Resource Event Agent Business Domain Ontology

Business domain ontologies offer great opportunities for facilitating communication between people in business, for improving the enterprise system engineering processes and for creating interoperability between enterprise systems. However despite these opportunities, their use in practice is still limited. This can be partly attributed to the lack of formal representation of these ontologies. This paper analyses current formalizations of the Resource Event Agent business domain ontology (REA-ontology) and investigates how this formalizations can be improved. Our approach recognises the opportunities that the conceptual modelling and database field can offer for ontology engineering and as a consequence a UML conceptualization of the business domain ontology is used as starting point of the formalization. Based on the transformation guidelines from UML to OWL and the current formalization of OWL we present some transformation dilemmas. It is our believe that these formalization problems are not unique to business domain ontologies and that other domain ontologies can also benefit from standard solutions to these formalization problems. 1 Problem and Context Business domain ontologies offer great opportunities for creating interoperability between enterprise systems. The successful application depends on the quality of the business domain ontology. Important ontological quality factors are reusability, reliability, shareability, portability and interoperability[1, 2]. In our view a business domain ontology with a strong theoretical basis which is engineered following a good methodology resulting in a proper formalisation will be of a much higher quality. This in turn will lead to more and successful applications. The last decade different business domain ontologies (Tove[3], Enterprise Ontology[4], REA Business Ontology[5], E3 value Ontology[6] and Business Model Ontology[7]) have been proposed. The developers of these business domain ontologies have different scientific backgrounds and this is shown in the different theoretical backgrounds of the ontologies. The creators of Tove and the Enterprise Ontology have an artificial intelligence background and the development ⋆ Corresponding Author of their ontologies gave them a more precise understanding of the ontology engineering process. The other ontologies share a more business-oriented focus. The Business Model Ontology is based on the balanced scorecard and has a strategic focus. The E3 value ontology is developed to support the requirements engineering process of an e-commerce project and should make sure that economic value is created. The REA-business domain ontology has a strong theoretical basis in accounting and micro-economics, and will be further described in detail later in this paper. Most of these domain ontologies have a strong theoretical basis but lack a formal description that can be used in practice. Tove and the Enterprise Ontology are both formalized by the Ontolingua framework but to our knowledge this has not lead to much usage in practice. For the development of a formal representation of the Business Model Ontology[7] and the REA business domain ontology [8] Protégé 2000 was used. With the release of the OWL plug-in for Protégé this has also resulted in an OWL formalization of these business domain ontologies. The E3 value ontology is not formalized and according to Gordijn ([6]) this is not required because of the mainly communication focus of the ontology. In [7] the benefits of formalizing the ontology are recognized. In the case of the Business Model Ontology the formalisation has led to a more precise specification of the business domain constructs and relations [9] and the formalization also creates a lot of opportunities in business management research [10]. The Inforge Group of the University of Lausanne is currently investigating how their formalized business model ontology can support new methods and computer-tools for diverse fields as business model design, business strategy and Information Technology/ Information Systems alignment. A formalization of the conceptualization of the application domain helps the developers to analyse their proposed ontology by comparing it with reality and can more easily expose critical issues. Formal languages describe the meaning of knowledge precisely and this supports automatic reasoning, which can be used for checking the consistency of the ontology[11]. A formal description also makes it easier to map different ontologies and find similarities between ontologies. Generally a formal description will improve the acceptance of the business domain ontology and will facilitate the development of applications. The Resource Event Agent business ontology (REA-ontology)[5] is another business domain ontology that offers great possibilities because of its strong theoretical basis and its unique structural characteristics. Its foundation in microeconomics(Theory of the Firm), strategic concepts (Porter’s Value Chain[12]) and basic accounting principles holds great promises for enterprise system design and creating interoperability between enterprise systems. The accounting background of the REA-ontology is evidenced by its core construct: economic duality. This means that each increment event in the business’s resources is linked with a corresponding decrement event. This constraint thus ”forces the business analyst or designer to consider explicitly the causal links between events and resources [13]” and should lead to more complete business models when the REA business domain ontology is used during enterprise system design. Unfortunately unlike the Business Model Ontology, the REA-ontology is underspecified as an ontology. The terminology of the constructs of the REAontology is sometimes inconsistent and confusing [14]. The proposed definitions, relations and constraints need to be converted into a formal language to discover inconsistencies and to analyze operational use[15]. A more formal conceptualization in an ontology language will improve the definition of the constructs and will prove that the REA-ontology can offer real support for enterprise system design and creating interoperability between enterprise systems. The machine readable REA-ontology can be used to develop tools for business modelling and can offer support for supply chain collaboration [16]. In this paper we take the first step towards developing a formal representation of the REA-ontology in OWL. In the next section the current specification, conceptualization, formalization and implementations of the REA business domain ontology are described. In the third sections this current description and some existing formalization guidelines are used to discuss some ’UML to OWL transformations’ that can be used to formalise the REA-ontology. Finally, the last section outlines the conclusions and our future research. 2 Existing Resources and Past Work The formalization of the REA business domain ontology must be the result of a structured ontology development process. Our approach is based on the Methontology Framework developed by [17] but mainly focuses on the development oriented activities. The management and support activities that support the ontology development process are also important and will surely improve the development process but they are not the main focus of this paper. In the next subsections the current specification, conceptualization, formalization and implementation of the REA business domain ontology is described. 2.1 Specification REA Business Domain ontology For almost twenty years the REA model was widely used as an educational instrument for teaching business students how to design accounting databases [18], while its use in system development practice was limited to a few companies[19]. Recently there has been a remarkable increase in researchers’ and practitioners’ interest in the model because of two reasons. First, the REA model developers were involved in a number of international standardization efforts for e-collaboration systems (e.g. ISO Open-EDI initiative, UN/CEFACT, OAG, eBTWG). This participation has resulted in the adoption of (parts of) the REA model as a business process ontology in the UMM business process and information model construction methodology [20] and the ECIMF system interoperability enabling methodology [21]. Second, the REA model has been proposed as a theoretical basis for the reference models that underlie ERP systems [22]. Both developments are witnesses of the REA model’s importance in the current and future enterprise systems landscape. The original REA-model was developed by McCarthy in 1982 and presented as a semantic model for the development of accounting systems[23]. Over the years McCarthy and Geerts changed focus and started to consider REA as a business domain ontology, which resulted in extensions to the basic REA model. These include the modelling of accounting phenomena at different levels of abstraction (value chain, process and task) and additional ontological primitives and axioms(commitment events, type images)[5]. 2.2 Conceptualization of the REA Business Domain ontology For the description of the REA-ontology the recent work of Geerts and McCarthy can be used[15, 24]. In these papers REA-ontology constructs and the relations between them are presented by means of ER diagrams or UML class diagrams. Table 1 summarises the most important definitions. Table 1. REA-ontology concepts definitions[5, 15, 24] REA-construct Definition Business Process a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer [25]. Economic Event Economic Events represent increments or decrements of the value of the resources. Economic events in the exchange processes represent transfer of control of an economic resource from one economic agent to another, where one agent provides other agent certain rights for the resource. Economic events in the conversion processes represent changes of the features of the resources. Business Event a significant occurrence in time that enterprise management would like to plan, control or evaluate. The REA business ontology exists of a three-level architecture for presenting economic activities. Based on the work of [12] and [26] an enterprise is represented by a value chain, which is seen as an network of business processes [27]. A business process is in turn an aggregate of Economic Events. According to the REA-ontology each economic event is part of a pattern of relations between three kind of objects that can be identified in every economic exchange or conversion process: economic resources, economic agents and economic events. Each economic resource is linked with an economic event that causes its inflow or outflow (stock flow). Furthermore every economic event that results in a resource inflow (e.g. a purchase) must be paired by an event that results in a resource outflow (e.g. a cash disbursement), and vice versa (duality). The participation relationship describes the agents involved in an Economic Event. This simple ontological pattern forms the basis of the REA-ontology and is derived from McCarthy’s original REA model(figure 1)[23]. Fig. 1. REA model [23] However to accomplish the economic events (economic exchange or conversion) an ordered sequence of actions, called business events, are needed. ”Business Events illustrate the task-decomposition structure of the workflow needed to accomplish the paired Economic Events ([15], p.8).” The relations between the three levels of modelling abstractions (value chain, business process, economic event) are shown in the Three-Level Architecture Model (Fig. 2). The formalization presented in this paper addresses only the middle layer of this architecture. The formalization of the other layers is considered as future work. Fig. 2. Three-Level Architecture Model based on Geerts and McCarthy[15] The basic REA-model shown in Figure 1 has been extended with additional concepts and axioms. One of the extensions is the commitment concept. Based on Ijiri the REA-ontology defines a commitment ”as an agreement to execute an economic event in a well defined future that will result in either an increase of resources or a decrease of resources”([28], p. 130). The commitment concept is linked with economic event by a ’fulfill’ association. Similar to the duality relationship between economic events a reciprocal relationship is defined between commitments. A reciprocal commitment establishes an economic agreement which can be of two type: a schedule (for conversion processes) or a contract (for exchange processes) [15]. The original REA paper ([23]) also expressed the need for an additional economic claim construct for capturing temporal(like payables) or more enduring (like loans) imbalances in duality relationships. If a decision is made to reify the duality imbalance, then two relationships become needed: (1) from the claim to the economic event that materializes it, and (2) from the claim to the economic event that settles it [13]. So far the presented business domain ontology only consists of past, present and future economic phenomena. This operational infrastructure is extended with a knowledge infrastructure that conceptualizes the abstract phenomena that characterize the actual economic phenomena [29]. The abstraction used in the REA business ontology is typification, which captures descriptions that apply to a group of actual phenomena. This abstraction adds a knowledge layer for planning and control above the operational infrastructure. The knowledge infrastructure contains the following types of abstract classes: Economic Resource Type, Economic Event Type and Economic Agent Type. These classes can be associated with the type image relations: ’policies’ and ’standards’. In the REA business ontology ’policies’ are defined as abstractions that restrict the legal configurations of the actual phenomena and ’standards’ define blueprints for the actual phenomena [15]. The knowledge and operational infrastructure interact by the economic commitment concept as this is both an operational and abstract phenomena. Commitments promise to execute economic events in the future and their specification is abstract because usually commitments consists of type-level designation of expected behaviour [15]. Figure 3 presents a summary overview of the operational and knowledge infrastructure of the REA ontology at the business process level in a UML class diagram. It is based on the different class diagrams presented in the Geerts and McCarthy papers and it will be used for the development of the formal representation of the REA-ontology. Figure 3 contains also the different specialisations of the basic REA constructs. Important to notice is that not only the entities are further specialized but also the relationships (represented by associations and association classes). Fig. 3. UML Class-diagram Business Process Layer REA-ontology 2.3 Current formalization REA business domain ontology Currently the formalization of the REA business domain ontology is very limited. In the papers of Geerts and McCarthy UML class diagrams are used for the description of the relations between the concepts. The ontological primitives and axioms are only described in text but are not formalized in a formal language. Geerts explored how XML technologies can be used for the operationalization of the REA enterprise ontology [30]. XML schema is used to formalize parts of the REA-ontology. Geerts chooses XML-schema because of the wide acceptance of this language but this will limit the use in practice of the REA-ontology and the use of ontology languages like RDF(S) and OWL offer far more opportunities. The semantic web layers proposed by W3C also indicate that XML / XML Schema layer is there to make sure that the semantic web definitions are compatible with XML standards. As a consequence XML-schema is not considered as an ontology language and the available ontology languages like OWL and RDF(S) are far more suited to capture a business domain ontology. However there were some efforts from other researchers to formalize the REA ontology. Borch et al.([31]) also formalised the REA-model with XML. The reason for choosing XML is similar to Geerts, the formalised REA-model is used on a Java platform where XML is widely supported by a range of transformation and verification tools. However in the proposed application (confer infra) of the REA-model UML could also be used. Bialecki was the only one that explored ontology languages and tools for the formalisation of the REA ontology[8]. As part of the E-Commerce Integration Meta-Framework project he formalized the REA-ontology with Protégé and RDF(S). However his latest updates date from 2001 and the REA-ontology has been subject to different changes since 2001. Furthermore Bialecki also encountered some ’disputable issues’ and it is our intention to critical evaluate the choices made in order to improve the formalisation of the REA business domain ontology. In section 3 our approach is explained and we will also indicate how this approach differs from Bialecki. 2.4 Current implementation of the REA business domain ontology To our knowledge currently there is no implementation that uses the full REA business domain ontology. However because the REA-model was originally designed to support the conceptual design of accounting information systems, their are some applications in the software engineering context. Borch et al.([31]) use their XML formalization of the REA-model as a platform independent model (PIM) in the Model Driven Architecture (MDA) approach to software engineering. The main contribution of their work is the exploration of the MDA concepts in a domain specific context. In the First International REA Technology Workshop (2004) a lot of researchers explored how the REA business domain ontology could be operationalized. A lot of the proposed implementations were related to supply chain management (SCM) and enterprise resource planning (ERP). Building business systems based on the REA business ontology can enhance the interoperability and adaptability of the system. 3 Formalization in OWL In the ontology engineering field many different approaches are used for the formalization of an ontology. However, many authors have recently recognised the opportunities that the conceptual modelling and database field can offer for ontology engineering. Conceptual modelling approaches have been designed to give a semantically rich description of the universe of discourse and ”could, at least to some extent, handle the description of the conceptualisation that is the subject of some ontology” ([32], p. 25). In our approach we wish to use the UML class diagram presented in the previous section as an intermediate for the formal representation of the ontology. The mapping between UML and OWL is based on the work of [33] who compare UML with DAML and give some rules for the mapping between UML and DAML. In our transformation we will use these rules as guidelines for the mapping between the UML class diagram of the operational infrastructure of the REA-ontology and OWL. At this stage RDF(S) could also be used, but we expect that in a later stage when additional constraints will incorporated, OWL will offer the best solution. In this research paper we will not present the whole formalization of the REA business domain ontology, but some formalization dilemmas we encountered during our approach. The whole formalization saved as an Protégé project is available at http://users.ugent.be/fgailly/phd. Some of the transformations from UML to OWL are very straightforward, but in other cases it is hard to determine the most appropriate transformation. Table 2 gives some examples of the straightforward transformations. UML classes were transformed in OWL classes and for the specialisation of classes the OWL ’subClassOf’ construct was used. Table 2. Straightforward Transformations between REA ontology UML class diagram and OWL According to the guidelines of [33] UML associations can be mapped into object properties, but during the formalization of the REA UML class diagram we came across additional problems. Unlike the examples in [33] all associations in the REA UML class diagram are bidirectional and as a consequence the associations had to be replaced by two directed associations which can then be formalised with two inverse object properties (table 3). For the naming of the inverse object properties the Protégé guidelines were followed. Every object property was prefixed with the word ’has’ and his inverse object property was prefixed with the word ’is’ and suffixed with ’of’. Our approach however remains under investigation and it could that be that formalizing an bidirectional association as only one object property is sufficient. Another problem is the use of association classes in the UML class diagram conceptualization. For the transformation of association classes two approaches are possible: (1) an association class can be considered as a sort of association and thus formalised as a ’subProperty’ or (2) the association class can be reified into a UML class which can be formalised following the transformations presented Table 3. Transformation dilemma REA ontology UML association and OWL before (table 4). In our opinion both approaches are correct, but it might be that the ’object property’ concept is too limited to formalize an UML association class. Following the UML specification an association class has both association and class properties, and the OWL object property concept supports some class properties (specialization, ...) but to our knowledge not all (disjunct subclass associations). Reifying the association class can be a quick solution to avoid these shortcomings. Table 4. Transformation dilemma REA ontology UML association class and OWL During the formalization it also became clear that the current specification and conceptualization of the REA business domain ontology is not sufficient. Geerts and McCarthy define associations (e.g. inflow, outflow, ...) that are in fact specializations of another association (stock-flow). A good formalization of these type of associations require that also the association ends of these type of associations are defined. This means that we must define which subclasses of the classes, that are part the more general association, can participate in the specializations of the more general association. This problem clearly shows that the specification and conceptualization can benefit from a good formalization. The so far presented transformations are not complete and additional problems will arise when other parts of the REA business domain ontology are formalized. The graphical representation will become more complex when more constructs and constraints are added and more complex mapping rules will be needed. In future research we will further evaluate existing mapping rules and how they can be used for the development of a formal representation of the REA-ontology. Finally, it is our intention to translate the mapping rules into an XSLT stylesheet which can be used for transforming the XMI representation of the UML diagrams into a representation in the target ontology representation language. 4 Conclusion and Future Research A correct formal representation of the REA-ontology offers great opportunities and will facilitate the operationalization of the REA-ontology. In this paper the transformation rules from UML to OWL are applied on the REA business domain ontology. It is shown that some transformations are not as straightforward as expected and we also find some prove that the formalization of an ontology can reveal shortcomings in the specification of the application domain ontology. In future research the UML class diagram will be further expanded with the business event specification of the REA-ontology. The REA-ontology also contains some additional constraints that are not incorporated in this paper and must be added in future research. Probably OCL will be needed to model the constraints in the UML class diagram and therefore it must be investigated how these constraints can be translated in OWL. However it could be that basic UML and OCL will not satisfy needs for representation of ontology concepts that are borrowed from Description Logic. Maybe the use of UML profiles can offer a solution or maybe basic UML needs to be extended with additional elements[33, 34]. In this paper the main focus lies on the transformation from UML class diagrams into an OWL representation. It is however our intention to improve every step of the ontology development process and this in the specific case of business domain ontologies. It is our intention to compare, evaluate and improve every existing business domain ontology and this should eventually result in successful applications.